Embedded firmware has a large dependency on the hardware environment in which it is being used. There can be a great deal of variance in the type of memory or other components used, board layout, or thermal solutions. Unlike user preferences which can be changed after the firmware is running on a processor, these hardware dependencies may prevent the firmware from functioning in any manner. Generally, the firmware manufacturers create different firmware builds for each different hardware configuration. These builds are all created at the same time by a “build engineer” or by an automated process.
The limitation of the generating different builds in this manner is that these can not be changed or updated easily in the field by a support person. In this regard, a request is generally made to the originator of the firmware builds to make the change. With firmware build teams located all over the world, it may take days if not weeks to be able to make and test a simple change.
Supporting multiple hardware configurations may be done at the original creation of the firmware binary images. However, after the images are created, a new or an updated firmware image may need to be created from scratch to handle a different hardware configuration. A separate user area of flash memory may be allocated for hardware configuration settings. However, under such circumstances, the firmware which needs to be running generally needs to be able to write these settings or an external flash burning tool is required. In addition, since the settings are decoupled from the firmware image, a great deal of care is required to keep the settings and firmware in sync with each other to accommodate firmware changes or updates.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with the present invention as set forth in the remainder of the present application with reference to the drawings.